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Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document describes a Uniform Resource Name Namespace 
Identification (URN NID) for the International Organization for 
Standardization (ISO). This URN NID is intended for use for the 
identification of persistent resources published by the ISO standards 
body (including documents, document metadata, extracted resources 
such as standard schemata and standard value sets, and other 
resources). 
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1. Introduction 


The International Organization for Standardization (ISO) was created 
by international agreement in 1947. ISO is a network of the national 
standards institutes of many countries, on the basis of one member 
per country, with a Central Secretariat in Geneva, Switzerland, that 
coordinates the system. ISO acts as a bridging organization in which 
a consensus can be reached on solutions that meet both the 
requirements of business and the broader needs of society, such as 
the needs of stakeholder groups like consumers and users. 


Further information is provided at http://www.iso.org/iso/about.htm. 


The core mission of ISO is to develop technical standards 
constituting technical agreements that provide the framework for 
compatible technology worldwide. ISO standards contribute to making 
the development, manufacturing, and supply of products and services 
more efficient, safer, and cleaner. They make trade between 
countries easier and fairer. 
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Every participating ISO member institute (full members) has the right 
to take part in the development of any standard that it judges to be 
important to its country's economy. No matter what the size or 
strength of that economy, each participating member in ISO has one 
vote.  ISO's activities are thus carried out in a democratic 
framework where each country is on an equal footing to influence the 
direction of ISO's work at the strategic level, as well as the 
technical content of its individual standards. Although the ISO 
standards are voluntary, the fact that they are developed in response 
to market demand, and are based on consensus among the interested 
parties, ensures widespread applicability of the standards. 
Consensus, like technology, evolves and ISO takes account of both 
evolving technology and evolving interests by requiring a review of 
its standards at least every five years to decide whether they should 
be maintained, updated, or withdrawn. 


ISO publishes International Standards and other technical 
specifications that are cited in the definitions of required or 
expected practices in many industries in many nations. These 
Specifications contain dictionaries of standard terms, catalogues of 
reference values, definitions of formal languages, formal schemata 
for information capture and exchange, specifications for standard 
practices, and other information resources of general use to 
international trade and industry. ISO wishes to create and manage 
globally unique, persistent, location-independent identifiers for 
these resources. 


This specification defines the syntax for URNs that identify 
documents developed by the International Organization for 
Standardization (ISO) in accordance with the standards development 
procedures defined in the ISO/IEC Directives, Part 1 [ISODIR-1] and 
the ISO supplement [ISODIR-S] and processed by the ISO Central 
Secretariat. The syntax extends to identify document metadata and 
resources related to these documents or otherwise associated with 
them. It does not extend to products derived from these documents 
and published by ISO (e.g., handbooks, compendia) or documents at or 
below the Technical Committee level. Revisions of this specification 
may define syntax for URNs in this namespace that identify other ISO 
objects, when the ISO community defines a requirement for such 
identifiers. 
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2. Specification Template 
2.1. Namespace ID 

"iso" 
2.2. Registration Information 


Version 2.1 
Date: 2007-12-13 


2.3. Declared Registrant of the Namespace 


J. Goodwin 
ISO Central Secretariat 


March 2008 


International Organization for Standardization (ISO) 


Case Postale 56 

CH-1211 Geneva 20 

Switzerland 

E-mail: goodwin@iso.org 
2.4. Declaration of Structure 


2.4.1. Definition 


The Namespace Specific Strings (NSSs) of 


all URNs assigned by ISO 


will conform to the syntax defined in Section 2.2 of [RFC2141]. 


The NSS has the following ABNF [RFC5234] 


NSS — std-nss 


Specification: 


All URNs conforming to this specification begin the NSS with the 


prefix "std:" to denote the restriction to documents developed by 
the ISO standards development procedures as defined in the ISO/IEC 
Directives, Part 1 [ISODIR-1] and the ISO Supplement [ISODIR-S]. 
Prefixes that identify ISO objects of other kinds may be defined 
in future revisions of this specification. 


std-nss = "std:" docidentifier *supplement *docelement 
[addition] 


The prefix "std:" distinguishes an <std-nss>. An <std-nss> 
identifies the ISO document that is designated by the 
<docidentifier>, as extended or modified by any identified 
«supplement». (An «std-nss» that identifies all parts of a 
multipart ISO document is a special case as described under the 
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element <partnumber>.) If the <std-nss> contains an «addition» 
element, the NSS identifies a resource extracted from the ISO 
document or otherwise associated with it (see below). 


docidentifier = originator [":" type] ":" docnumber [":" partnumber] 
[[":" status] ":" edition] 
[":" docversion] [":" language] 


<docidentifier> provides the complete identification of an ISO 
document. Each of its component elements is described below. 


originator = "iso" / "iso-iec" / "iso-cie" / "iso-astm" / 


"iso-ieee" / "iec" 


<originator> is the organization (usually an international body) 
from which a document emanates. 


Current values: 


iso = International Organization for Standardization 

iec = International Electrotechnical Commission (IEC), or 
Commission Electrotechnique Internationale 

iso-iec = jointly developed by ISO and IEC 

iso-cie = jointly developed by ISO and the Commission 
Internationale d’Eclairage (CIE) 

iso-astm = jointly developed by ISO and the American Society for 
Testing and Materials (ASTM) International 

iso-ieee = jointly developed by ISO and the Institute for 


Electrical and Electronics Engineers (IEEE) 


Revisions of this specification may define additional values. 


type 


= "data" / "guide" / "isp" / "iwa" / 
"pas" / "r" / "tr" / "tg" / "tta" 


«type» designates the ISO deliverable type. If the «type» element 
is not present, the classification is "international standard". 


Other 
data 


guide 


current values: 


Data (document type no longer published) 


= Guide 
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isp = International Standardized Profile 
iwa = International Workshop Agreement 
pas = Publicly Available Specification 
r = Recommendation (document type no longer published) 
tf = Technical Report 
ts = Technical Specification 
tta = Technology Trends Assessment 
docnumber = DIGITS 


<docnumber> is the reference number assigned to the document by 
ISO and/or IEC. An ISO document may comprise a single document, 
or two or more separate parts each of which is identified by 
<partnumber>. 


partnumber = "-" 1*( DIGIT / ALPHA / "-" ) 


<partnumber> is the reference number that identifies a part of a 
multipart standard. 


Where it is required to refer to a multipart ISO document in its 
entirety, this can be designated by omitting the «partnumber» 
element. However, this precludes the possibility of using any 
further elements except «addition». 


NOTE: The option to refer to a multipart ISO document by omitting 
the «partnumber» element has been included to align with the 
provision in the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] 
subclause 6.2.2 of making an undated reference to all parts of an 
ISO document. It is only permissible to use this option where the 
URN is referring to a multipart ISO document in its entirety. 
Since the use of this option precludes the designation of the 
elements «status» and «edition», it is implicit that the URN needs 
to remain valid irrespective of any future changes to the 
multipart document (see the rules for undated references given in 
the ISO/IEC Directives, Part 2, 2004 [ISODIR-2] subclause 
6.6.7.5.2). This shall be taken into consideration in the use 
(and maintenance) of any URN specification employing this option. 
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NOTE: In the case where the multipart document comprises different 
types of ISO deliverable, the «type» of the core part (usually 
part 1) applies. See the example "Reference to a resource related 
to all parts of a multipart document". 


Except for the case where it is required to refer to a multipart 

document in its entirety, the element «partnumber» is required if 
the identified resource is a part of an ISO document. Otherwise, 
this element is not used. 


status = ( "draft" / "cancelled" ) / stage 
«status» indicates the publication status of the document. When 


the «status» element is not present, the NSS refers to a published 
document. Other values: 


draft document that has not yet been accepted for 


publication by international ballot 


document that has been deleted or withdrawn 


cancelled 
stage = "stage-" stagecode ["." iteration] 

«stage» indicates the stage code and iteration of the document. 
stagecode = DIGIT DIGIT "." DIGIT DIGIT 

<stagecode> is the harmonized stage code in accordance with ISO 

Guide 69:1999, “Harmonized Stage Code system (Edition 2) -- 

Principles and guidelines for use" [ISOGUIDE69]. 


iteration = "y" DIGITS 


<iteration> is a sequential number that refers to a specific 
iteration of the project’s lifecycle through the designated stage. 


If no <iteration> is specified, the reference is to the highest 
iteration available for the specified stagecode. 


NOTE: In the ISO Central Secretariat project management database, 
the <iteration> is referred to as the "project version". 


edition = "ed-" DIGITS 
<edition> designates a specific edition of the document. (DIGITS 
is the (sequential) edition number.) If no <edition> is 


specified, the NSS refers to the latest edition. 
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docversion = "y" (simpleversion / isoversion) 


simpleversion DIGITS 

<docversion> designates the version number of a document's 
«edition». It is altered by correction (corrected version; 
Technical Corrigendum) or amendment (Amendment; Addendum) and is 
distinct from a revision, which changes the edition number. 


In the «simpleversion», the first version published is 1, and each 
subsequent correction or amendment increases the version number by 
Ts 


If no <docversion> is specified, the reference is to the highest 
version number available for the denoted <edition>. 


Current values of <simpleversion>: 
1 - first version published 
2 — corrected version published 


isoversion = baseversion *includedsuppl 


baseversion DIGITS 


-" suppltype supplnumber [ "." supplversion ] 


includedsuppl 
An <isoversion> can be linked to a simpleversion by defining an 
existing simpleversion as baseversion and listing all the 
«supplement» elements (corrections and amendments) incorporated 
into that version. 
Examples for the «isoversion» (internal ISO version) scheme: 


1 = first version of standard 


1l-amdl.vl1 = first version of standard incorporating first 
version of Amendment 1 


1l-amd1l.vl-amd2.vl = first version of standard incorporating 
first version of Amendment 1 and first version of Amendment 2 


1-amdl.v2-amd2.vi1-amd3 = first version of standard 


incorporating corrected version of Amendment 1, first version 
of Amendment 2, and highest version of Amendment 3 
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1-cor3 = first version of standard incorporating highest 
version of Technical Corrigendum 3 


1-amdl-cor3 = first version of standard incorporating highest 
version of Amendment 1 and highest version of Technical 
Corrigendum 3 


language = monolingual / bilingual / trilingual 
monolingual = "en" Jf "fp" f "pt Jomagw f Tar" 
bilingual = "en,fr" / "en,ru" / "fr,ru" 
trilingual = "en,fr,ru" 


«language» designates the official ISO language(s), or the 
language of an official translation, in which the document 
(object) is processed and published by ISO (excluding languages 


that constitute only specific elements of the content). The value 
is one or more alpha-2 codes, each of which designates a language, 
as specified in ISO 639-1 [150639-1]. If no language element is 


Specified, «en» is assumed. 


NOTE: Although [1I1S0639-1] recommends that language codes be 
written in lowercase, this ABNF definition allows the use of 
uppercase language codes because in ABNF [RFC5234], terminal 
symbols defined as literal strings are explicitly 
case-insensitive. This case distinction does not carry any 
meaning (see Section 2.9) and it is recommended to use language 
codes in lowercase. For additional information about the usage of 
language tags in information objects, see [RFC4646]. 


supplement = "i" suppltype ":" supplnumber 
[":" supplversion ] [":" language ] 
suppltype = "amd" / "cor" / "add" 
supplnumber = DIGITS 
supplversion = "v" DIGITS 


<supplement> designates a technical alteration of or addition to 
an ISO standard that does not result in a new <edition> or 
<version>. Each <supplement> may be one of the three types, 
designated by <suppltype>: 
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amd = Amendment -- a document that alters and/or adds to 
previously agreed upon technical provisions in an existing 
ISO document; an amendment is subject to acceptance by 
ballot in accordance with the ISO/IEC Directives, Part 1, 
2004 [ISODIR-1] subclause 2.10.3 


cor = Technical Corrigendum -- a document that corrects a 
technical error or ambiguity, or updates the ISO document in 
such a way that the modification has no effect on the 
technical normative elements; a Technical Corrigendum is not 
balloted -- see the ISO/IEC Directives, Part 1, 2004 
[ISODIR-1] subclause 2.10.2 


add = Addendum -- (document type no longer published) Addenda were 
documents that changed (by correction, addition, or 
deletion) the technical requirements of an ISO document; an 
addendum was subject to acceptance by ballot in accordance 
with the ISO/IEC Directives, Part 1. (Addenda are included 
in this RFC because some of them are still valid.) 


Supplements are numbered consecutively per ISO document, and 
within each supplement type. 


<supplnumber> identifies the number of the supplement. 


<supplversion> designates the version of a published supplement. 
At present, only two versions are used in practice: when a 
supplement is published, it is version 1. If that supplement is 
subsequently corrected by issuing a corrected version, as 
designated by the term "Corrected" on the cover page together with 
a date, the corrected version is version 2. 


The language of a supplement can be different from that of the 
document. For example, a supplement may apply to only one of the 
languages of a bilingual document. For such cases, the language 
of a supplement can be identified using the «language» element 
defined above. The interpretation is the same, except that it 
applies only to the supplement. 


docelement = "S" o( "elause" / "figure" 7 "table" / "term" ) "i" 
elementnumber / elementrange 
*( "," elementnumber / elementrange ) 
elementnumber = ( ALPHA / DIGITS ) *( "." DIGITS ) 
elementrange = elementnumber "-" elementnumber 
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<docelement> identifies one or more numbered subdivisions of a 
document. Types of numbered subdivision are specified in the ISO/ 
IEC Directives, Part 2 [ISODIR-2]. This RFC currently specifies 
forms for reference to clauses, figures, tables, and terms only. 
It does not provide for reference to subfigures. Revisions of 
this specification may define additional values. 


«clause» represents the selection of one or more clauses or 
subclauses of the document. «figure» represents the selection of 
one or more figures of the document. «table» represents the 
selection of one or more tables of the document. «term» represents 
the selection of one or more terms of the document. 


<elementnumber> designates a numbered subdivision in a document, 
where the type of subdivision is identified by the literal 
"clause", "figure", "table", or "term". When the first character 
of «elementnumber» is a digit, the reference is to the subdivision 
designated by that digit string and by any additional digit 
strings separated by periods. When the first character of 
<elementnumber> is alphabetical, the reference is to the 
corresponding Annex, and to the subdivisions designated by 
additional digit strings. 


The form «elementnumber» HYPHEN «elementnumber» designates a range 
of subdivisions, and the form «elementnumber» COMMA 
<elementnumber> designates a list. A list can contain ranges. 


addition — techdefined / isodefined 
techdefined = ":tech" *techelement 
techelement = «unspecified» 

isodefined = «unspecified» 


«addition» is an additional element of the NSS intended to 
identify a representation of an ISO document, an extract from an 
ISO document, or some related information set, as a resource in 
its own right. 


<techdefined> represents an associated or embedded resource 
defined by the committee that develops or maintains the identified 
document. All such «addition» elements begin with the prefix 
"stech". 
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<isodefined> represents associated or embedded resources defined 
by the ISO Central Secretariat. The definition of an «addition» 
element beginning with any symbol other than «tech» is reserved to 
the ISO Central Secretariat. 


The syntax of the «addition» element is not specified in this RFC. 
Specific syntax for this element will be specified as needed by 
the ISO Central Secretariat, or by the individual committee that 
has the responsibility for developing or maintaining the 
identified document. It is necessary that these definitions 
comply with the rules for lexical equivalence specified in Section 
2.9 and take into account the process for identifier resolution as 
discussed in Section 2.8. 


DIGITS = DIGIT *DIGIT 
DIGIT = $x30-39 ; 0-9 


ALPHA = $x41-5A / $x61-7A ; A-Z / a-z 
Basics of the ABNF notation used 


" "literals (terminal character strings); terms not in quotes are 
non-terminals 


A alternatives 
[] indicates an optional rule 


() indicates a sequence group, used as a single alternative or as a 
single repeating group 


<a>*<b> indicates that the following term or group can repeat at 
least «a» and at most «b» times; default values are 0 and 


infinity, respectively 


; comment 


2.4.2. Examples 
o Language handling: 


urn:iso:std:iso:9999:-1:ed-1:en 
refers to the 1st edition of ISO 9999-1, in English 


urn:iso:std:iso:9999:-1:ed-1:en, fr 


refers to the lst edition of ISO 9999-1, in English/French 
(bilingual document) 
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o Originators/document type: 


urn:iso:std:iso-iec:tr:9999:-1:ed-1:en 
refers to the lst edition of ISO/IEC TR 9999-1, in English 


o Status: 


urn:iso:std:iso-iec:9075:-3:cancelled:ed-2:en 
urn:iso:std:iso-iec:9075:-3:stage-95.99:ed-2:en 

both refer to the cancelled 2nd edition of ISO/IEC 9075-3, in 
English 


urn:iso:std:iso-iec:9075:-3:draft:ed-4:en 
urn:iso:std:iso-iec:9075:-3:stage-30.60:ed-4:en 
both refer to the draft 4th edition of ISO/IEC 9075-3, in English 


urn:iso:std:iso:128:-20:en 
urn:iso:std:iso:128:-20:stage-90.20:ed-1:en 

both refer to the published (90.20 = under 2nd periodic review) 
lst edition of ISO 128-20, in English 


urn:iso:std:iso:128:-71:cancelled:ed-1:en 
urn:iso:std:iso:128:-71:stage-30.98.v2:ed-1:en 

both refer to the cancelled (30.98 = project deleted) 1st edition 
of ISO 128-71, in English; the second example refers specifically 
to the 2nd iteration (projectversion) at stage 30 


o Non-numeric part number: 


urn:iso:std:iso:9999:-A02:ed-1:en 
refers to the 1st edition of ISO 9999-A02, in English 


o Reference to a resource related to all parts of a multipart 
document: 


urn:iso:std:iso:20022:tech:xsd:camt.001.001.01 

refers to a "techdefined" resource (i.e., a resource defined by 
the committee that develops or maintains the identified document) 
associated with ISO 20022 in its entirety; in this example, the 
techdefined part comprises ":xsd:camt.001.001.01" 


NOTE: At the time of drafting of this schema, ISO 20022 comprises 
5 parts: parts 1 and 2 are International Standards; parts 3 to 5 
are Technical Specifications. Therefore, the <doctype> 
"international standard" is used in the URN. 
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o 


Docversion handling: 


urn:iso:std:iso:9999:-1:ed-1:v2:en 
refers to the corrected English version of the 1st edition of ISO 
9999-1 


urn:iso:std:iso:9999:-1:ed-1:vl1-amdl1:en 
refers to the version comprising the 1st edition of ISO 9999-1, 
incorporating the latest version of Amendment 1, in English 


urn:iso:std:iso:9999:-1:ed-1:v1:en,fr:amd:1:v2:en 

refers to the 2nd version of Amendment 1, in English, which amends 
the 1st version of edition 1 of ISO 9999-1, in English/French 
(bilingual document) 


urn:iso:std:iso:9999:-1:ed-1:vl-amdl.v1:en,fr:amd:2:v2:en 
(isoversion scheme) 

refers to the corrected version of Amendment 2, in English, which 
amends the document comprising the lst version of edition 1 of ISO 
9999-1 incorporating the 1st version of Amendment 1, in English/ 
French (bilingual document) 


urn:iso:std:iso:5817:ed-2:v2:en:cor:1:en 

refers to the 1st version of Technical Corrigendum 1, in English, 
which amends the corrected version of edition 2 of ISO 5817, in 
English 


Supplement handling: 


urn:iso:std:iso:9999:-1:ed-2:en:amd:1 
refers to Amendment 1 to the 2nd edition of ISO 9999-1, in English 


urn:iso:std:iso:9999:-1:ed-2:en:amd:1:v2 
refers to the corrected version of Amendment 1 to the 2nd edition 
of ISO 9999-1, in English 


urn:iso:std:iso:9999:1:ed-2:en,fr:amd:2:en 
refers to Amendment 2 in English to the 2nd edition of ISO 9999-1, 
in English/French (bilingual document) 


urn:iso:std:iso:9999:-1:ed-2:en:amd:1:cor:1 
refers to Corrigendum 1 to Amendment 1 to the 2nd edition of ISO 
9999-1, in English 
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o Docelement handling: 


urn:iso:std:iso:105:-c12:ed-1:en:clause:a.1,a.2 
urn:iso:std:iso:105:-c12:ed-1:en:clause:a.1-a.2 

both refer to clauses A.1 and A.2 in the 1st edition of ISO 
105-C12, in English 


urn:iso:std:iso:9999:-1:ed-1:v1- 

amdl.vl:en, fr:amd:2:v2:en:clause:3.1,a.2-b.9 (isoversion scheme) 
refers to (sub)clauses 3.1 and A.2 to B.9 in the corrected version 
of Amendment 2, in English, which amends the document comprising 
the lst version of edition 1 of ISO 9999-1 incorporating the 1st 
version of Amendment 1, in English/French (bilingual document) 


urn:iso:std:iso:9999:-1:ed-2:en:amd:1:term:3.2,3.3,3.4.1- 
3.4.4,3.12 

refers to the terms 3.2, 3.3, 3.4.1 to 3.4.4, and 3.12 in 
Amendment 1 to the 2nd edition of ISO 9999-1, in English 


2.5. Relevant Ancillary Documentation 


ISO/IEC Directives, Part 1 [ISODIR-1] and Part 2 [ISODIR-2], and ISO 
supplement [ISODIR-S]. 


2.6. Identifier Uniqueness Considerations 


Assignment of URNs for documents in the requested namespace will be 
managed by the ISO Central Secretariat, which will ensure that the 
assigned URNs are consistent with the ISO Directives for unique 
identification of ISO documents. 


Assignment of URNs for Technical Committee resources related to ISO 
documents will be managed by the Technical Committees developing or 
maintaining those documents. As indicated above, each such URN will 
extend the URN for the containing document via the element 
«addition». The responsibility of the Technical Committee will 
therefore be to ensure the uniqueness of the techdefined «addition» 
element that constitutes the identifier for the resource within the 
document namespace, and thus the uniqueness of the overall resource 
identifier within the requested namespace. 


2.7. Identifier Persistence Considerations 


Assigned URNs will not be reused and will remain valid beyond the 
lifecycle of the referenced resources. However, it should be noted 
that although the URNs remain valid, the status of the referenced 
resource may change. 
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2.8. Process for Identifier Resolution 
Resolving document identifiers: 


This schema has been developed with the intent that a URN 
identifying an ISO document can be transformed to a valid http URI 
by replacing the requested URN namespace prefix ("iso") and the 
"std:" prefix with the domain name "standards.iso.org", replacing 
all occurrences of ":" within the identifier with "/", and 
converting characters to lowercase. (ISO is planning to develop a 
website implementation to support these URIs.) 


Examples: 


urn:iso:std:iso:9999:-1:ed-1:en: corresponds to 
http://standards.iso.org/iso/9999/-1/ed-1/en/ 


urn:iso:std:iso-iec:tr:9999:-1:ed-1:en: corresponds to 
http://standards.iso.org/iso-iec/tr/9999/-1/ed-1/en/ 


urn:iso:std:iso:9999:-1:ed-2:en,fr:amd:2: corresponds to 
http://standards.iso.org/iso/9999/-1/ed-2/en, fr/amd/2/ 


Resolving identifiers for «addition» resources: 


For URNs in the requested namespace that refer to additional 
resources related to ISO documents, the ISO Central Secretariat 
will specify the resolution procedure at the time it defines the 
syntax for the corresponding «addition» to the «std-nss». In most 
cases, those resources will be maintained on an ISO website, as 
extensions to the http URIs described above. 


2.9. Rules for Lexical Equivalence 


URNs are lexically equivalent if they are octet-by-octet equal after 
the following preprocessing: 


1. normalize the case of the leading "urn:" token 
2. normalize the case of the NID 

3. normalize the case of any $-escaping 

4. normalize the case of all elements 


Further information is specified in [RFC2141], Section 5. 


Goodwin & Apel Informational [Page 16] 


RFC 5141 ISO URN Schema March 2008 


2 


2. 


2: 


3 


10. Conformance with URN Syntax 
No special considerations. 
11. Validation Mechanism 
None specified. 
12. Scope 
Global. 
Namespace Considerations 
The ISO-specific requirements are as follows: 
o globally unique, persistent identifiers 


o location-independent identifiers 


o human-interpretable identifiers 


o a scheme applicable to paper documents as well as machine-readable 
documents 


o a scheme applicable to conceptual documents and explicit forms of 
documents 


o a scheme applicable to resources extracted from documents 
o a scheme applicable to "metadata" associated with documents 


o a scheme in which the identifier assignment is managed by the ISO 
Central Secretariat 


Location-independence: Because the publication of ISO standards is a 
complex arrangement involving multiple development organizations and 
national standards institutes, a given ISO document may be available 
in a number of forms from a number of sources. This makes it 
important to have a document identifier that is global in scope, 
widely and uniformly used, and independent of the text source used by 
any given reference. 


Human-interpretable: Many, perhaps most, references to documents 
appear in text generated by human authors. It is important that an 
author familiar with the scheme be able to generate a correct URN for 
a document for which the author has the ISO reference (or document 
identifier). Conversely, it is important that a reader unfamiliar 
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with the scheme be able to identify the URN as a reference to an ISO 
document, particularly an ISO standard, and also to recognize 
identifiers for forms, languages, or metadata sets. 


Paper documents: Older ISO standards that are commonly used as 
industrial references exist only in paper form or in earlier 
machine-readable forms that are not commonly used on the Internet. 

It is important to have a document identifier scheme that extends to 
these resources as well. (In fact, many of these have been converted 
to Internet forms, and others are being converted, but it is 
important that the identifier be independent of the form in which the 
document can be obtained at any given time.) 


Conceptual documents vs. representation forms: Because ISO documents 
are regularly maintained and re-published in multiple forms, it is 
important to have document identifiers that denote the conceptual 
document, without regard to publication form. At the same time, it 
is necessary for certain types of use to be able to refer to specific 
editions, or specific publication forms (for example, editions in 
different languages, or to PDF or HTML versions). This URN 
specification allows for the identification of these different types 
of use in the «isodefined» part of the «addition» element. 


Document extracts: ISO standards may contain formal specifications in 
machine-processable languages, or formal specifications that also 
have representations in machine-processable languages. It is useful 
to be able to extract these specifications in machine-processable 
form as separate resources, and therefore it is necessary to give 
these "extracted resources" global identifiers derived from the 
document identifier using a consistent identification scheme. 


Document metadata: Certain uses of documents and document text, 
primarily bibliographic, also extract information from the documents, 
and that information, commonly called "metadata", is organized in 


machine-readable forms conforming to other standards. These metadata 
sets then become resources in their own right. It is important to 
give them URN identifiers consistent with the document identification 
Scheme. 

4. Community Considerations 
The ISO community is broad in two dimensions. In one dimension, its 


documents are developed and used in a large variety of industries and 
professions: natural sciences, manufacturing, construction, 
transportation, information technology, social sciences, etc. In the 
other dimension, it is a community of expert developers, standards 
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managers, publishers, professional users, and consumers. And 
Internet information technologies are a part of common professional 
practice in all of these areas in both dimensions. 


ISO standards are cited in business agreements, in professional 
publications, in product descriptions, and in standards development 
and publication activities. When these citations appear in 
electronic form, the references must be unambiguous. 


The information technology community is itself very active in the 
development and use of standards, and many ISO publications are 
developed by and for that community. When an Internet information 
exchange uses a form specified in an ISO document, or a terminology 
defined in an ISO document, it is often necessary to identify that 
ISO specification in the envelope surrounding the exchange. That 
identification should use a formal, unambiguous identifier in a form 
readily recognized by the receiving software, and possibly by the 
ultimate human recipient of the information. 


In order to facilitate the use of existing and emerging Internet 
technologies for all of these purposes, URNs conforming to [RFC2141] 
represent the most useful form of formal, globally unambiguous 
identifiers. The use of a managed namespace for such identifiers, 
following a consistent scheme for identifying ISO documents and their 
derivatives, would be of significant benefit to the entire ISO 
community. 


It would give professional users in many industries a standard 
form for electronic reference to ISO standards in HTML, XML, PDF, 
etc., documents. 


It would give software developers a standard form for reference to 
ISO standard protocols, schemata, languages, data sets, etc. 


It would give standards developers a standard form for reference 
to other ISO publications in various stages of development. And 
it would give them a standard form for creating identifiers for 

machine-readable information sets contained in, or derived from, 
the specifications. 


It would give standards managers and publishers a formal uniform 
scheme for reference to specific publications, editions, and 
versions of ISO documents. 


While the assignment of identifiers under this scheme is managed by 
the ISO Central Secretariat, the processes by which the identified 
objects arise and acquire such identifiers are the result of 
agreements made by the member bodies. Every such project is 
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initiated by one member body and reviewed and voted on by the others. 
Every accepted project is open to participation by any member body, 
and in fact, participation by a certain minimum number (usually 5) of 
member bodies is required for acceptance of most projects. In 
general, the member bodies are open professional and industrial 
organizations reflecting broad expertise and national interest. 


It should be noted that ISO documents in draft state are not usually 
made available outside the ISO standards development community. 
Making them available to professionals outside of the process might 
well mislead the recipients into premature adoption of practices that 
are not yet completely specified or have not yet achieved consensus, 
and therefore may well change. 


It should also be noted that ISO documents are not, in general, 
freely available over the Internet. Rather, there are complex 
agreements between ISO and its member institutes as to the rights to 
the publications and the corresponding fees that may be charged for 
paper or electronic copies of various editions. Some ISO documents 
are freely available, and some are freely available in certain forms. 
In general, derivatives of ISO documents (schemata, metadata sets, 
etc.) are freely available over the Internet in the appropriate 
machine-readable forms. A URL associated with a URN in the requested 
namespace may therefore lead directly to a machine-readable copy of 
the text of the document or derivative, or it may lead to a site that 
can provide that text for a fee, or it may lead to a site that can 
only sell a paper copy of the document. Bearing in mind that ISO is 
a network of otherwise independent institutes, this behavior is 
simply a property of the ISO community. 


Finally, it should be noted that, for many purposes, reference to the 
ISO standard is what is required, and only the product engineer or 
software tool builder actually needs access to the text. This 
request is based on the need to standardize the form of reference, 
not the means of access. 


5. IANA Considerations 
IANA has assigned "iso" (29) as a formal NID. 
The ISO Central Secretariat will maintain a registry of the 
permissible values for the elements comprising the NSS. Information 
may be obtained from the following address: urn@iso.org. 


6. Security Considerations 


The ISO URN Namespace ID shares the security considerations outlined 
in [RFC3406], but has no other known security considerations. 
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Appendix A. Alternative Naming Schemes 


Before initiating this request, ISO attempted to find an existing or 
currently proposed URN NID scheme that might be used instead of a 
dedicated scheme. Two existing schemes were carefully considered 
because they clearly meet part of the requirements: 


o The OID scheme, documented in [RFC3061] 
o The PublicId scheme, documented in [RFC3151] 


The OID scheme is derived from the joint ISO/ITU-T ASN.1 
object-identifier scheme specified in [ISO/IEC8824-1:2002] (original 
edition 1984; [RFC3061] cites the 1988 [CCITT] edition of the 
encoding rules in [ISO/IEC8825:1987]. This standard assigned the 
registry authority for all identifiers in the { iso(1) ) namespace to 
ISO, and therefore, ISO controls the registry of all identifiers 
beginning "oid:1:". And in fact, ISO has developed, and is using, an 
identification scheme under ASN.1 that meets most of the above 
requirements. ISO could clearly define a use of the OID scheme that 
would be adequate to meet all of its technical objectives, although 
it would further complicate the current ASN.1 scheme. 


The original intent of ISO 8824 was to permit both a human-readable 
form for the identifier, to maximize intuitive recognition, and an 
encoding that minimized the number of bits needed to communicate an 
OID value over a network.  Regrettably, the encoding chosen in RFC 
3061 is much closer to the minimal bits encoding than to the 
human-readable one. The NSS for the OID scheme consists entirely of 
digits and punctuation. For example, the ASN.1 identifier { iso(1) 
standard(0) 7852 part(2) edition(3) } becomes: urn:oid:1:0:7852:2:3. 


This is difficult for a human reader or author to interpret. It is 
also easy to mistype, and the scheme contains no "check-digits", 
which makes it difficult to validate, leading to the propagation of 
URNS that are invalid or valid but erroneous. Finally, the 
all-numeric form conveys no hint of the name of the responsible 
organization, and therefore no hint of any URL that might aid a human 
reader in interpreting the reference. The OID scheme makes all of 
the required identifiers technically possible and technically useable 
by software, but for all practical purposes, the OID URNs are useful 
only to software. 


The PublicId scheme is derived from Standard Generalized Markup 
Language (SGML) [1S08879:1986] and [ISO/IEC9070:1991] bibliographic 
catalogue forms. Narrowed to ISO publications, it is adequate for 
the unique global persistent identification of published documents, 
in both paper and machine-processable form. 
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Importantly, the PublicId scheme does not have a "conceptual 
document" notion -- it identifies specific publications and editions. 
"Weak identification" could be used to implement the conceptual 
document concept, but the PublicId scheme does not document that 
interpretation. In any case, the PublicId scheme does not extend to 
draft documents, which are often referenced in pilot implementations, 
to separate forms of a document, or to resources extracted from 
documents. It supports only those metadata elements that are defined 
in SGML. The scheme could be extended to do most of these, but the 
ISO-specific extensions would not in general extend to the much 
broader base of documents identified by PublicIds. (Version and 
edition management practices vary significantly across publishers, 
depending on their milieu.) Further, the ISO Central Secretariat 
could not and should not control the registry of such URNs. 


ISO therefore concluded that the alternative schemes are not adequate 
to meet the requirements of the ISO community. 


Whilst requesting a new namespace for ISO documents and their 
derivatives, ISO does not wish to discourage the use of these other 
identifiers for ISO publications. The PublicId form, in particular, 
is useful for referring to ISO publications in a larger bibliographic 
information space. 


Appendix B.  ABNF Definition of Namespace ID - "iso" (Informative) 

NSS = std-nss 

std-nss = "std:" docidentifier *supplement *docelement 
[addition] 

docidentifier = originator [":" type] ":" docnumber [":" partnumber] 
[[":" status] ":" edition] 
[":" docversion] [":" language] 

originator = "iso" / "iso-iec" / "iso-cie" / "iso-astm" / 


"iso-ieee" / "iec" 


; iso = International Organization for 
k Standardization 
; iec = International Electrotechnical 


; Commission (IEC), or Commission 
7 Electrotechnique Internationale 


; iso-iec = jointly developed by ISO and IEC 
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type 


docnumber 
partnumber 


status 


stage 


Goodwin & Apel 


ISO URN Schema 


; iso-cie 


March 2008 


jointly developed by ISO and the 


$ Commission Internationale d'Eclairage 


; (CIE) 


; iso-astm - 


jointly developed by ISO and the 


; American Society for Testing and 


; Materials 


; iso-ieee 
i Institute for 


(ASTM) 


International 


jointly developed by ISO and the 


Electrical and 


; Electronics Engineers (IEEE) 
"data" / "guide" / "isp" / "iwa" / 
"pas" / "yg" / Weep / "cuv Vi "rta" 


; data = Data (document type no longer published) 
; guide = Guide 
; isp = International Standardized Profile 
; iwa = International Workshop Agreement 
; pas = Publicly Available Specification 
EOL = Recommendation (document type no longer 
; published) 
ame oe a! = Technical Report 
; ts = Technical Specification 
; tta — Technology Trends Assessment 
DIGITS 
"-" 1*( DIGIT / ALPHA / "-" ) 
( "draft" / "cancelled" ) / stage 
; draft = document that has not yet been 
E accepted for publication by 
$ international ballot 
; cancelled = document that has been deleted or 
E withdrawn 
"stage-" stagecode ["." iteration] 
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stagecode = DIGIT DIGIT "." DIGIT DIGIT 
iteration = "v" DIGITS 
edition = "ed-" DIGITS 
docversion = "y" (simpleversion / isoversion) 
simpleversion - DIGITS 

; 1 first version published 

; 2 = corrected version published 
isoversion = baseversion *includedsuppl 
baseversion = DIGITS 
includedsuppl = "-" suppltype supplnumber [ "." supplversion ] 
language = monolingual / bilingual / trilingual 
monolingual = "en" J “fre /' "yg" J "es" / "ap" 
bilingual = "en,fr" / "en,ru" / "fr,ru" 
trilingual = "en,fr,ru" 
supplement = "i" Suppltype ":" supplnumber 

[":" supplversion ] [":" language ] 
suppltype = "amd" / "cor" / "add" 

; amd - Amendment 

; cor = Technical Corrigendum 

; add = Addendum 
supplnumber = DIGITS 
supplversion = "v" DIGITS 
docelement Same oC “okause" 9/- "figure" -J "table" / "term" ) ":" 

elementnumber / elementrange 

*( "," elementnumber / elementrange ) 
elementnumber = ( ALPHA / DIGITS ) *( "." DIGITS ) 
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elementrange = elementnumber "-" elementnumber 
addition = techdefined / isodefined 
techdefined = "itech" *techelement 
techelement = «unspecified» 

isodefined = «unspecified» 

DIGITS = DIGIT *DIGIT 

DIGIT = $x30-39 ; 0-9 

ALPHA = $x41-5A / $x61-7A ; A-Z / a-z 
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